The PCR4 and PCR7 checks were relying on the BootCurrent EFI variable to
identify the EV_EFI_BOOT_SERVICES_APPLICATION event in the TCG log that
corresponds to the launch of the initial OS loader. This is proving
problematic on some systems:
- Whilst some firmware populates a Boot variable containing a load
  option with a path matching the OS loader and sets BootCurrent to
  point to this when booting from removable media, some firmware
  implementations dosn't set a path that matches the OS loader, and this
  path doesn't match any event in the TCG log.
- Some systems don't seem to have BootCurrent set at all when booting
  from removable media.

Instead, assume that the first OS-present
EV_EFI_BOOT_SERVICES_APPLICATION event that isn't Absolute is the
initial OS loader. If it isn't, the PCR4 checks will fail as expected
because os the mismsatched digest. We have to have a special case for
Absolute here because some systems measure this launch as part of
OS-present.

This also makes the checks a bit more permissive where firmware bugs
don't cause problems with generating profiles:
- The PCR4 checks no longer enforce that there can be only one
  EV_OMIT_BOOT_DEVICE_EVENT event.
- The PCR4 checks no longer enforce that there cannot be a EV_EFI_ACTION
  "Calling EFI Application from Boot Option" if there is a
  EV_OMIT_BOOT_DEVICE_EVENT event. We already don't enforce the
  existence of the EV_EFI_ACTION event if there is no
  EV_OMIT_BOOT_DEVICE_EVENT event even though it should be there,
  because we know that some firmware misbehaves here.
- The PCR4 checks no longer gate the reading of the SysPrepOrder and
  SysPrep variables on the BootOptionSupport flags.

Fixes: canonical#517
Fixes: canonical#519

…ariables in unit tests